Request Routing

partitioning 的最後一個段落想講的問題：如果我想寫入或讀取 foo 這個 key，我該連哪個節點？

我們稱這個一般化的問題為 service discovery (服務發現) ，其實這個問題其實不只資料庫會遇到，只要是分散式系統都會有，尤其想以 high availability (高可用性) 為目標的系統。

我們有 3 個 routing 方法回答 client 這個問題，如下圖：

1. 讓 client 隨便連一個節點 (ex: 用 round-robin load balancer)，然後如果剛好中了就直接查該節點，要不就 forward 到對的節點，然後在 pass 該節點的結果回去。
2. 建一個 routing tier ，然後用它負責接所有想知道 partition 在哪個節點上的 request。
3. client 有能力知道他該去哪裡，然後直接連該節點，這個方法需要 client 知道每個節點各被分派了哪些 partition。

Ok，現在有個新問題是，要怎麼讓這 3 個 routing 方法知道節點被分派了哪些 partition？

許多分散式系統都會依賴一個協調服務像 ZookKeeper 來幫助它們追蹤叢集的 metadata，如下圖所示，每個節點需要跟 ZooKeeper 註冊並告知它 partition 的資訊，然後由它教上面講的 3 個 routing 方法，也就是黑色線的部份。

最常見用 ZooKeeper 來當 partition 分配管理的就是 Kafka, HBase 了，我們公司開發的數據系統也是使用 ZooKeeper 做 service discovery，只是現在會慢慢轉移到 Consul 上了。

另外，Cassandra 使用了不同的方法，他們使用 gossip protocol 來傳播節點中所有的叢集變化，request 來的時候會送到任一節點，然後在 forward 到對的節點 (等於圖 6-7 的方法 1)，這個模型的好處就是不需要依賴一個外部的服務。

總結

我們在 Day 27 講了為什麼需要做 partition，然後介紹 2 個 partition 的策略：

• Key range partitioning

• Hashing partitioning

然後講怎麼做 secondary index (Day 28)：

• Document-partitoin index
• Term-partitoin index

最後就是 Day 29 的 rebalancing 和今天的 routing 啦！

鐵人心得

完成了這本書 Design Data Intensive Applications 的一半章節書摘了，這本書真心推薦給工程師看，很多策略都需要在你了解這些概念後才能針對各公司不同的資料特性做最適合的設定，所以裡頭不會告訴你該選哪個策略，好的概念放諸四海皆準，這本書能讓你掌握這些概念，希望明年能把後 6 章寫完啦，感謝各位。